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DETAILED ACTION 

1. This communication is in response to Amendment filed 8/10/05, claims 1, 9, 16, 17, 21 have been 
amended, claims 1-21 have been examined and remain pending. 

2. Acknowledgment in this application as a continuation-in-part under 35 U.S.C. 120 to Application 
No. 09/438,817, entitled "SECURE REMOTE ACCESS TO ENTERPRISE NETWORKS", filed 
November 10, 1999, abandoned as of 10/27/04. 

3. Amendment to claim 1 obviated previous raised objection, therefore is hereby withdrawn. 

4. Claims 9, 16, 21 as filed on 8/10/05 have been amended, however status indicated "original", 
correction is required. 

Claim Rejection under 103 

5. Quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in 
this Office action may be found in previous office action. 

6. Claims 1-9, and 17-21 are rejected under 35 USC 103(a) as being unpatentable over Jammes et. 
al. (US 6,484,149 Bl) (referred to as Jammes hereafter) in view of Gregg et. al. (US 6,5 16,416 B2) 
(referred to as Gregg hereafter) in further view of (US 6,519,617) Wanderski et. al. (referred to a 
Wanderski hereafter). 

Regarding claim 1, Jammes teaches a system as shown on Figs. 1-3, comprising: 

the remote device having browser (102) capabilities to accommodate a request inputted by a 
"subscriber" user to access the "subscriber information" data (col 9/lines 1-8; col 6/lines 17-20, 41-58, 
user input see col 21/lines 11-14), said a "remote access" device (102) communicated via a "data" 
network (104) (Fig. 1, col 8/lines 34-41); 
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a "an application gateway" server (106) hosting the subscriber information (col 12/lines 1-10, col 
6/lines 22-30 and information including col 6/lines 66-col 7/line 7), the application gateway server 
comprising: 

a navigation module (350/352) for receiving data in a predetermined (e.g. HTTP and/or URL) 
format (see Fig. 3, col 17/lines 55-58) and accessing information (called "device specific") associated 
with said received data (col 9/lines 1-10, col 7/lines 8-17, 30-39, col 12/lines 1-10); 

a data module (1 14) for obtaining (e.g. said subscriber) information requested (325/324 of Fig. 3, 
col 29/lines 29-38) and passing said subscriber information to the navigation module (Fig. 3, col 9/lines 
10-21, 45-51, 65-66, col 8/lines 46-67 and col 16/lines 42-49); 

a rendering module for obtaining "requisite browser" displayable data based on desired action 
(e.g. subscriber's request) (col 43/lines 55-63) and current state associated with said session (col 50/lines 
1-30), including converting (354) requested subscriber information to a format specific to subscriber 
device specific format e.g. client readable format (col 7/lines 15-65) and 

verifying subscriber identity using information inputted by the subscriber, including name, 
password or cookie (col 49/lines 15-32); however Jammes does not explicitly teach means ("session 
module") for maintaining "temporary" data about the subscriber, and where data provided by the 
rendering module is used by the navigation module to modify said received data for providing to said 
remote data access; 

Gregg disclosure within the invention's field of endeavor, teaches a hosting server including a 
session (52) module (col 7/lines 42-47) for maintaining session related data (i.e. "temporary data") 
associated with a subscriber's session(s) (col 5/lines 21-24 & col 11/lines 19-30), and for 
communicating/interacting with a subscription access server (34) receiving subscriber access requests (col 
6/lines 41-45), session data including temporary data regarding a session (col 12/lines 1-13, 60-62); 
further teaching 

a rendering module (74) for obtaining data based on desired action (e.g. apply for a different 
subscription) and current state (e.g. existing subscriber) (col 8/lines 39-67), the obtained data including 
browser related data "requisite" (col 36/lines 32-38); 

an authentication module associated with said data source module for verifying subscriber 
credentials (authenticates: col 4/lines 50-54, validates or verifies; col 6/lines 26-31 based on subscriber 
information "credentials"; col 6/lines 66-col 7/line 27); however Gregg does not teach where data 
provided by the rendering module is used by the navigation module to modify said received data for 
providing to said remote data access; 
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Wanderski disclosure related to allowing end users to access information from a plurality of 
devices (Fig. 2), Wanderski teaches "wherein said rendering module communicates with said navigation 
module using browser related information provided by the rendering module modify the response data for 
said remote access device in accordance with said browser specific information". Specifically, wherein 
software "blocks" modules (col 9/lines 32-39) configured to perform the following functions: a software 
block (320) determines browser related information (col 10/lines 33-40), software module (330) using 
said information provided by module (320) (col 10/lines 8-23, 48-55), generating data for said remote 
access device in accordance with said browser related data (col 9/lines 21-27, 55-65, including 
assembling, col 10/lines 48-67). 

It would have been obvious to one ordinary skilled in the art at the time the invention was made 
given the teachings of Jammes for accessing web sites in a e-commerce environment over the Web, the 
teachings of Gregg for improving subscription access system over the Internet would be readily apparent. 
One ordinary skilled in the art would be motivated to combine the teachings of Jammes and Gregg for 
customizing and/or personalizing the information provided to the consumer and/or subscriber, based on 
the browser type and the sites visited by the subscriber, providing client readable/rendable based on the 
obtained and stored browser type device information making information frequently accessed readily 
available without user explicitly requesting it. One would be further motivated to modify data for remote 
access device according to the type of device, browser, network limitations or user preferences because in 
doing so download time and/or storage capacity need can be reduced dynamically, as suggested by, 
Wanderski. 

Regarding claims 2-3, a database associated with said data source module (114 of Fig. 3), wherein said 
authentication module compares user data with user stored data, said user stored data being stored on said 
database (Gregg: authenticates: col 4/lines 50-54, validates or verifies; col 6/lines 26-31 based on 
subscriber information "credentials"; col 6/lines 66-col 7/line 27) and wherein said predetermined format 
comprises data in URL format (Jammes: Fig. 3, col 17/lines 55-58). 

Regarding claim 4, wherein said subscriber information comprises enterprise specific information 
(Jammes: col 6/lines 32-40 and Gregg: col 1/lines 20-27). 

Regarding claim 5, said navigation module extracts an action request from said data in the predetermined 
format (Jammes: col 17/lines 55-61), passes the action request to the data source module which retrieves 
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any necessary information based upon the action request (Jammes: col 17/lines 61-col 18/line 15); and 
said navigation module retrieves a "browser specific screen" data corresponding to the action request 
from the rendering module (Jammes: col 7/lines 15-65 and Gregg: col 36/lines 32-38). 
Regarding claims 6-9, the ability to receive information and data requests in remote access device specific 
formats and convert said information and data requests into data packets (Jammes: col 7/lines 15-65, col 
17/line 61-col 18/line 15) and wherein the data network comprises the Internet (Jammes: col 5/lines 48- 
52, col 6/lines 14-21), wherein the data network comprises a dedicated network connection (Jammes: col 
5/lines 48-52), and wherein the remote access device comprises a personal computer (Gregg: col 9/lines 
1-15). 

Regarding claim 17, this claim is substantially the same as limitations discussed on claims 1, 3, 10-11, 
same rationale of rejection is applicable. 

Regarding claim 18, wherein verified credentials some reside on a (called "enterprise") database (Gregg: 
authenticates: col 4/lines 50-54, validates or verifies; col 6/lines 26-31 based on subscriber information 
"credentials"; col 6/lines 66-col 7/line 27). 

Regarding claims 19-20, substantially the same as limitations in claims 1, 3, 10-11, same rationale of 
rejection is applicable and wherein said navigation module parses said URL subscriber request into 
identifiable segments, at least one segment comprising a requested action (Jammes; col 17/lines 55-col 
18/line 5). 

Regarding claim 21, this claim is substantially the same as claim 4, discussed above, same rationale of 
rejection is applicable. 

7. Claims 10-16 are rejected under 35 USC 103(a) as being unpatentable over Jammes in view of 
Gregg. 

Regarding claim 10, as discussed on claim 1, further comprising the steps of 

receiving a "subscriber information" request in a predetermined format (e.g. HTTP and/URL) 
(Jammes: see Fig. 3, col 17/lines 55-58); 
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"navigating the access and transmission 55 parsing or scanning and/or analyzing the requested 
subscriber information (Jammes; col 17/lines 55-col 18/line 5), 

said transmission of the requested subscriber information being in a "subscriber device specific 55 
predetermined format (Jammes: see Fig. 3, col 17/lines 55-58); said access and transmission navigating 
step comprising: 

"compiling" gathering or collecting subscriber information based on said subscriber information 
request (Gregg: col 8/lines 39-67 and col 36/lines 32-38); 

"assembling" processing and displaying said subscriber information into a "device specific 
format" associated with the subscriber device, wherein said predetermined format for said subscriber 
information request differs from said subscriber device specific predetermined format (Jammes: device 
specific format conversion col 7/lines 15-65 and browser type data col 36/lines 32-38); and 

transmitting the assembled and rendered subscriber information to said subscriber device 
(Jammes: col 20/lines 45-col 21/lines 64, rendering accessed/retrieved content, col 6/lines 40-45). 

Regarding claim 11, a database associated with said data source module (114 of Fig. 3), wherein said 
authentication module compares user data with user stored data, said user stored data being stored on said 
database (Gregg: authenticates: col 4/lines 50-54, validates or verifies; col 6/lines 26-31 based on 
subscriber information "credentials"; col 6/lines 66-col 7/line 27) and wherein said predetermined format 
comprises data in URL format (Jammes: Fig. 3, col 17/lines 55-58). 

said navigation module extracts an action request from said data in the predetermined format 
(Jammes: col 17/lines 55-61), passes the action request to the data source module which retrieves any 
necessary information based upon the action request (Jammes: col 17/lines 61-col 18/line 15); and said 
navigation module retrieves a "browser specific screen" data corresponding to the action request from the 
rendering module (Jammes: col 7/lines 15-65 and Gregg: col 36/lines 32-38). 

Regarding claim 12, parsing said subscriber information into an action task and a page specific task, and 
compiling content data based on the information identified on the parsing step (Jammes; col 17/lines 55- 
col 18/line 5). 

Regarding claim 13, verifying user credentials using information maintained with subscriber information 
at a (called local) database (Gregg: authenticates: col 4/lines 50-54, validates or verifies; col 6/lines 26-31 
based on subscriber information "credentials"; col 6/lines 66-col 7/line 27). 
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Regarding claims 14 and 16, wherein said subscriber information comprises enterprise specific 
information (Jammes: col 6/lines 32-40 and Gregg: col 1/lines 20-27). 

Regarding claim 15, compiling comprises seeking requested information from a ("local") database 
(Jammes; col 1 7/lines 55-col 1 8/line 5). 

Response to Arguments 

8. Regarding claims 1 and 17 rejected as being unpatentable over Jammes in view of Gregg, it is 
argued (p. 8 of remarks) that the applied prior art does not teach added limitation, i.e. "a rendering module 
which cooperates with a navigation module to reformat data for a particular access device". 

In response to the above-mentioned argument, applicant's interpretation of the applied prior art 
has been fully considered. However, according to instant invention's disclosure: The rendering module 
locates the appropriate screen for the browser used and action desired and passes this to the navigation 
module [see 0026]. Rather, navigation module 502 merely receives URL data, acts accordingly by 
assembling the appropriate response to the URL action request, and returns browser appropriate data. 
Render or rendering module 504 provides the necessary browser specific information to the navigation 
module 502 for transmission back to the particular device [see 0073]. For any particular data needed to 
render the browser appropriate screen, the render module 504 obtains screen data from screen database 
506 and passes that data to navigation module 502 [see 0074]. The navigation module 502 passes the 
screen type through to the render module 505 such that it can be used repeatedly, while passing through 
user data, such as headers for emails, as well as user data or user parameters, such as eight user specific e- 
mail headers, and thus tells the rendering module 504 what to place in certain locations within the 
browser page. Navigation module 502 therefore hands off the request for a particular screen, email 
headers, title inbox, and so forth, to the rendering module 504, which locates the appropriate screen in the 
screen bank 506 and locates the necessary template, fills the template with the data provided by the 
navigation module 502, and passes the completed screen to the navigation module. Rendering motfute 
504 may hold hundreds of screens, including several screen 8510s for the various types of user devices 
available. Rendering module 502 determines the type of browser being used by reading the header 
associated with the URL received and determines whether the device is a Netscape browser (if the word 
"mozilla" appears in the header), a Windows CE device if a Windows CE browser, and so forth. Once the 
type of device has been identified, that information is passed to render to retrieve and compile the 
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appropriate information for transmission [see 0075]. Once the navigation module has compiled the 
requisite information from the session module, rendering module, and data access module, the browser 
specific data is sent back through interface module 501 and to the device [see 0078]. 

Claimed clause "wherein said rendering module interacts with said navigation module to 
cause said navigation module to reformat said data for said remote access device", has been 
fully considered. Added clause has been interpreted [AS BEST UNDERSTOOD], 

"wherein said rendering module communicates with said navigation module using 
browser specific information provided by the rendering module modifies the response data for 
said remote access device in accordance with said browser specific information". 

It is respectfully noted that: (i) "interfacing", "interact" are a broad terms any 
communication reads on it, (ii) "to cause said navigation module" has been reviewed however, 
in view of recited in the specification, "navigation module 502 merely receives URL data, acts 
accordingly by assembling the appropriate response to the URL action request, and returns browser 
appropriate data. Render or rendering module 504 provides the necessary browser specific information 
to the navigation module 502 for transmission back to the particular device" [see 0073]. 

Thus, "to cause said navigation module" means that the navigation module merely receives and 
acts accordingly; (iii) "reformat" will be interpreted broadly in context with the disclosure cited, thereby, 
meaning assembling. 

9. Regarding claim 10 rejected under 35 USC 103(a) over Jammes in view of Gregg, it is 
argued (p. 8 of remarks) that the office action alleges Jammes discloses every element of the 
claim, thereby claim 10 should have been rejected under 102(e). 

In response to the above-mentioned argument, office action rejection has been carefully reviewed. 
However, applicant's attention is directed to page 5 of office action mailed 5/12/05, the following 
limitation has been rejected citing portion(s) of the Gregg reference: "compiling" gathering or collecting 
subscriber information based on said subscriber information request (Gregg: col 8/lines 39-67 and col 
36/lines 32-38). 

10. Regarding claims 1 and 17 rejected over Jammes in view of Gregg, it is argued (p. 8-9) that the 
applied prior art fails to teach maintaining temporary data associated with the subscriber information. 
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In response to the above-mentioned argument, applicant's interpretation of the applied prior has 
been carefully reviewed. However, Gregg teaches a hosting server including a session (52) module (col 
7/lines 42-47) for maintaining session related data (i.e. "temporary data") associated with a subscriber's 
session(s). Specifically, a session manager is provided which builds sessions for every valid subscriber so 
that it can keep the transaction list that contains all of the tasks performed during a subscriber's session 
(see col 5/lines 21-24). Each web transaction during the session is reported to the session manager 52 by 
the shared object 66 so that the session manager 52 can build a list of transactions for the user (see col 
7/lines 53-56). The session manager 52 maintains a binary tree list of all the active subscriber sessions . 
For every session, it maintains a linked list of all the transactions for that session (see col 12/lines 1- 
13). Gregg teaches maintaining associated with subscriber information associated with a session. 
Further Gregg teaches, wherein said session module interfaces with said module that receives 
data in a predetermined format. Specifically, the system a server, wherein the subscriber 36 
request protected content and that request is communicated to the subscription access server 34 which 
then commands the subscriber to login (col 6/lines 23-26). A session manager 52 interacts with the 
clearinghouse 30 and the subscription access server 34 and a hardware access key 54, which is connected 
to the subscriber 36 (col 6/lines 41-45). The server will call upon the subscription access functions which 
are defined in the shared object 66 which ensure that the subscriber is operating as a valid session and 
once there is an active session, these objects will grant permission and sends a message to the session 
manager 52 about a particular transaction so that the session manager can update its lists of transactions 
for the active session (col 7/lines 66-col 8/line 19). Thereby, Gregg teaches communicating or interacting 
with a subscription access server (34) receiving subscriber access requests (i.e. navigation module) (col 
6/lines 41-45). 

11. Regarding claims 1 and 17 rejected as being unpatentable over Jammes in view of Gregg, it is 
argued (p. 8 of remarks) that the applied prior art does not teach added limitation, "wherein said 
rendering module communicates with said navigation module using browser specific information 
provided by the rendering module modifies the response data for said remote access device in accordance, 
with said browser specific information '\ 

In response to the above-mentioned argument, applicant's interpretation of the applied prior art 
has been noted. Broadest reasonable interpretation in light of the specification has been applied. In this 
case, Wanderski teaches software "blocks" modules (col 9/lines 32-39) configured to perform the 
following functions: a software block (320) determines browser related information (col 10/lines 33-40), 
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software module (330) using said information provided by module (320) (col 10/lines 8-23, 48-55), 
generating data for said remote access device in accordance with said browser related data (col 9/lines 21- 
27, 55-65, including assembling, col 10/lines 48-67). 

12. Applicant's arguments filed 08/04/05 have been fully considered but not rendered persuasive. 

13. Reply to a final rejection or action must include cancellation of, or appeal from the rejection of, 
each rejected claim. If any claim stands allowed, the reply to a final rejection or action must comply with 
any requirements or objections as to form (see 1.113). If prosecution in an application is closed, an 
applicant may request continued examination of the application by filing a submission and the fee set 
forth in § 1.17(e) prior to the earliest of: (c) A submission as used in this section includes, but is not 
limited to, an information disclosure statement, an amendment to the written description, claims, or 
drawings, new arguments, or new evidence in support of patentability. If reply to an Office action under 
35 USC 132 is outstanding, the submission must meet the reply requirements of § 1.111 (see MPEP 
706.07) 

14. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office 
action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is 
reminded of the extension of time policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE MONTHS from 
the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing 
date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH 
shortened statutory period, then the shortened statutory period will expire on the date the advisory action 
is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later than SIX 
MONTHS from the date of this final action. 
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be directed to Prieto, B. whose telephone number is (571) 272-3902. The Examiner can normally be 
reached on Monday-Friday from 6:00 to 3:30 p.m. If attempts to reach the examiner by telephone are 
unsuccessful, the Examiner's Supervisor, Andrew T. Caldwell can be reached at (571) 272-3868. Any 
inquiry of a general nature or relating to the status of this application or proceeding should be directed to 
the receptionist whose telephone number is (703) 305-3800/4700. 



Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system, status information for published application may be obtained from 
either Private or Public PAIR, for unpublished application Private PAIR only (see http://pair- 
direct.uspto.gov or the Electronic Business Center at 866-217-9197 (toll-free). 
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Faxed to the Central Fax Office: 

(703) 872-9306 (old No. in service until Sept. 15, 2005), 
(571) 273-8300 (New Central Fax No.) 
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(703) 306-5631 for TC 2100 Customer Service Office. 
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